Coste total de la propiedad (TCO)

Historial de versiones

Versión	Fecha	Diferencia entre versiones
1.0	2024-02-08	Versión inicial del documento
2.0	2024-02-09	Finalización del documento
3.0	2024-02-10	Corrección del documento
4.0	2024-02-15	Corrección del documento
5.0	2024-02-16	Corrección del documento
6.0	2024-02-22	Corrección del documento
7.0	2024-03-01	Corrección del documento
8.0	2024-03-08	Corrección del documento
9.0	2024-03-10	Corrección del documento
10.0	2024-03-14	Actualización del documento
11.0	2024-03-19	Actualización del documento
12.0	2024-03-26	Actualización del documento
13.0	2024-04-05	Actualización del documento
14.0	2024-04-11	Actualización del documento
15.0	2024-04-12	Actualización del documento
16.0	2024-04-15	Actualización del documento

1. Introducción

En este documento, se establece el coste total de la propiedad respectivo al proyecto. Para ello, se tiene en cuenta el precio de desarrollo del proyecto, y sus estimaciones de precio de mantenimiento y operación. Es decir que va más allá del precio inicial de compra y tiene más sentido si lo analizamos como un gasto a largo plazo.

2. Costes de capital (Capex)

2.1 Costes de personal

2.1.1 Desarrollo

El equipo encargado del proyecto, está formado por 17 integrantes. Cada uno de ellos, tiene la obligación de dedicar al menos 10 horas semanales a dicho proyecto, como se establece en el proyecto docente de la asignatura de Ingeniería del Software Y Práctica Profesional (ISPP). Teniendo en cuenta esto y los sueldos por hora de los siguientes perfiles:

• Manager – 20.85 €/h
• Coordinador Software– 18.50 €/h
• Desarrollador– 11.25 €/h

Hay que tener en cuenta que a grandes rasgos, en este proyecto hay 1 jefe de proyecto y 3 coordinadores, los cuales dedicarán más tiempo a la gestión y gerencia, mientras que los 13 miembros restantes dedicaran más tiempo al desarrollo e implementación. Por lo tanto la estimación de costes de personal para las 15 semanas que dura el proyecto es la siguiente:

• 1 manager: 15 x 10 x 20.85 = 3127.50€
• 3 coordinadores: 3 x 15 x 10 x 18.50 = 8325.00€
• 13 desarrolladores: 13 x 15 x 10 x 11.25 = 21937.50€ Coste total de personal de desarrollo= 33390.00€

A esto, habría que restarle las horas dedicadas por el GDPR Officer y el Community Manager en sus respectivas horas de coordinador y de desarrollador. Sería para las 5 semanas restantes del proyecto:

• Coordinador: 5 x 3 x 18.50 = 277.50€
• Desarrollador: 5 x 3 x 11.25 = 168.75€

Entonces, el coste sería 33390.00€ - 277.50€ - 168.75€ = 32943.75€

Coste total personal desarrollo = 32943.75€

2.1.2 GDPR

En este sistema, se tratan datos sensibles y personales sobre familiares o personas. Esto hace necesario la introducción de una serie de roles y responsabilidades para garantizar el cumplimiento de las normativas de protección de datos, Reglamento General de Protección de Datos (GDPR por sus siglas en inglés).

En nuestro caso, donde el sistema solamente va a ser utilizado por los administradores, y donde no va a haber una gran cantidad de usuarios, suponemos que es suficiente con la introducción de un GDPR Officer. Suponemos también un sueldo medio de 22.50€ por hora, y una dedicación semanal de 3 horas. Por lo tanto, el coste de GDPR para las 5 semanas restantes de desarrollo del proyecto es de 22.50 x 3 x 5 = 337.50€.

2.1.3 Marketing

En este sistema, se ha decidido realizar una campaña de marketing para dar a conocer la aplicación a las organizaciones que la van a utilizar. Para ello, suponemos un Community Manager (CM) con un sueldo de 13,50€ por hora, y una dedicación semanal de 3 horas, para que se encargue de todo este tipo de tareas. Por lo tanto, el coste de marketing para las 5 semanas restantes de desarrollo del proyecto es de 13.50 x 3 x 5 = 202.50€.

2.1.4 Coste total de personal

El coste total de personal, teniendo en cuenta los costes de desarrollo, GDPR y marketing, es el siguiente:

• Coste total personal desarrollo = 32943.75€
• Coste total personal GDPR = 337.50€
• Coste total personal marketing = 202.50€

Coste total de personal = 32943.75€ + 337.50€ + 202.50€ = 33483.75€

2.2 Costes de material

Para cada integrante del equipo, suponemos un portátil o equipo de un precio aproximado de 950€. Teniendo en cuenta que contamos con una vida útil de 4 años por equipo, el precio equivalente para las 15 semanas de uso sería lo siguiente:

• En un año tenemos 52 semanas, si son 4 tenemos 208 semanas. Entonces el precio para las 15 semanas que dura el proyecto es 950/208 x 15 = 68.51 € por integrante

Coste total de material = 68.51 x 17 = 1164.67€

2.3 Costes de licencias externas

En este proyecto, para la CI/CD, se utiliza GitHub Actions, pues además se utiliza GitHub para el desarrollo de este. Hay que tener en cuenta el limite de minutos para la CI/CD.

GitHub Plan

Utilizando la calculadora de precios de GitHub podemos ver el precio de 2 jobs diarios de 5 minutos cada uno para cada mes, lo cual suponemos suficiente, que es de 2.22€. Por lo que el coste mensual de las licencias externas es de 2.22€.

GitHub Actions

El total de minutos mensuales sería de 2 x 5 x 30 = 300 minutos.

Como en la actualidad para los proyectos open source, como el nuestro, este plan es gratuito (ver plan de GitHub) pues el total se encuentra por debajo de los 2000 minutos mensuales, en nuestro TCO actual los costes de la licencia de GitHub siguen siendo de 0€.

Además, el resto de herramientas que pueden necesitar los desarrolladores externos a nosotros para la operación son de uso gratuito, como pueden ser los entornos de desarrollo integrados gratuitos como VSCode o sistemas de comunicación gratuitos como Discord.

2.4 Costes de Seguridad Social

También hay que tener en cuenta los costes de la Seguridad Social, en los que se incluyen, entre otros, los costes de cotingencias comunes, prestaciones por desempleo, contingencias profesionales, formación y el Fondo De Garantía Social (FOGASA). Para este cálculo, se ha utilizado una calculadora de costes de la Seguridad Social, donde se ha introducido el salario bruto de los trabajadores, el tipo de contrato y el porcentaje de cotización.

Costes de Seguridad Social

A continuación, podemos ver el coste de la seguridad social para cada uno de los perfiles que forman parte del proyecto:

• Manager: 1204,82€ mensuales. Teniendo en cuenta que nos quedan 5 semanas de proyecto, el coste total de la seguridad social para el manager es de 1204,82€ x 5 / 4 = 1506,03€
• Coordinador: 1069,02€ mensuales. Teniendo en cuenta que nos quedan 5 semanas de proyecto, el coste total de la seguridad social para el coordinador es de 1069,02€ x 5 / 4 = 1336,28€. Y contando que tenemos 3 coordinadores el coste total de la seguridad social para los coordinadores es de 1336,28€ x 3 = 4008,84€. Menos 213,8€ de las horas que uno de nuestros coordinadores dedica a GDPR. Total = 4008,84€ - 213,8€ = 3795,04€
• Desarrollador: 650,08€ mensuales. Teniendo en cuenta que nos quedan 5 semanas de proyecto, el coste total de la seguridad social para el desarrollador es de 650,08€ x 5 / 4 = 812,60€. Y contando que tenemos 13 desarrolladores el coste total de la seguridad social para los desarrolladores es de 812,60€ x 13 = 10541,80€. Menos 130,73€ de las horas que unode nuestros desarrolladores dedica al Marketing. Total = 10541,80€ - 130,73€ = 10411,07€
• GDPR Officer: 390,05€ mensuales. Teniendo en cuenta que nos quedan 5 semanas de proyecto, el coste total de la seguridad social para el GDPR Officer es de 390,05€ x 5 / 4 = 487,56€
• Community Manager: 234,03€ mensuales. Teniendo en cuenta que nos quedan 5 semanas de proyecto, el coste total de la seguridad social para el Community Manager es de 234,03€ x 5 / 4 = 292,54€

El coste total de la seguridad social es de 1506,03€ + 3795,04€ + 10411,07€ + 487,56€ + 292,54€ = 16292,24€

3. Costes de operación mensual (Opex)

En esta sección, se muestran los distintos costes relacionados con el mantenimiento del sistema, una vez está finalizado y completado, o también llamado OpEx (Operating Expenditure).

Los usuarios de la aplicación serán unos pocos voluntarios de la Tertulia Cofrade Cirio y Costal, exactamente dos personas el tesorero y el presidente, y de la Asociación Ciudadana de Ayuda al Toxicómano, donde la usarán tres personas. Por lo cual el uso y tráfico de nuestra aplicación va a ser muy limitado, por no decir insignificante. La infraestructura necesaria para mantener una aplicación con estas necesidades es mínima y más importante la carga de la aplicación no aumenta con el tiempo.

Por lo tanto en caso de que se duplicase o triplicase nuestro tráfico, el coste de operación no aumentaría y se mantendría constante. Esto es debido a que contaríamos como mucho con unos 12 o 18 usuarios en total de manera simultanea, y los costes que se explican a continuación suponemos que tienen límites suficientes para soportar esta carga.

3.1 Costes de despliegue

En nuestro caso, hay que tener en cuenta que contamos con el frontend, el backend y la base de datos. Se detalla así:

• Para FastApi, lo más rentable es utilizar algún servicio en la nube que ofrezca sus servidores a sus clientes, en este caso a nosotros y a nuestros clientes. Puesto que desplegarlo en un servidor propio conlleva grandes gastos y no estaría al alcance de esta asignatura. Dentro de los servicios en la nube, hemos estudiado y analizado las distintas opciones que encontramos en el mercado.
• NextJs, para que nuestro servicio sea accesible a sus usuarios necesitamos desplegar la aplicación en la nube. Para el despliegue de una aplicación NextJs en la nube hay multitud de servicios disponibles, pero considerando la situación del proyecto y la tecnología usada hay dos sistemas de hosting claros para usar. Estos son el servicio de App Engine de Google Cloud, debido al bono recibido por la empresa para el uso de este sistema, con un crédito de 100 dólares por desarrollador, y el hosting de Vercel que son los creadores y mantenedores del framework NextJs y es la mejor plataforma para desplegar aplicaciones realizadas con este framework, dando funcionalidades adicionales para NextJs que no te ofrece otro hosting.

3.1.1 App Engine de Google Cloud

El servicio ofrece dos tipos de entornos estándar y flexible, la diferencia entre los dos tipos es que el entorno flexible es autoescalable al aumentar la carga mientras que el estándar se escala de forma manual. En nuestro caso de uso donde la carga de la aplicación es estable a lo largo del tiempo será necesario el entorno estándar. Los costes de App Engine se cargan en base al tipo de instancia que se esté desplegando, mientras más recursos tenga un tipo de instancia más caro es su uso. Para la poca carga que va a recibir la aplicación con el uso de las instancias más pequeñas será suficiente para desplegar y usar la aplicación en Google Cloud. App Engine tiene preparado el tipo de instancia “F” para despliegues de aplicaciones Frontend, donde se podría usar una instancia “F1” siendo esta la de menor potencia de la clase “F”.

Instancia de tipo F

Por último el precio por hora para mantener una instancia de tipo “F1” activa y funcionando correctamente es de 0.06 dólares por hora. Pero App Engine también ofrece un nivel gratuito, donde no se aplicaran estos precios si el uso no supera un límite establecido por Google Cloud. Para las instancias de tipo “F” este límite es de 28 horas por día, con lo que se puede considerar el despliegue y mantenimiento gratuito para la aplicación. Además, App Engine ofrece otro tipo de instancia que es la “B”, la cual es una instancia preparada para el Backend. Esta instancia presenta distintos subtipos dependiendo de la velocidad y la capacidad.

Instancias de tipo B

En nuestro caso, como se comentó previamente, con la poca carga de usuarios que va a recibir la aplicación, el uso de las instancias más pequeñas será suficiente para el despliegue del backend. En este caso, la “B2” ofrece un precio de 0.1158€ por hora de funcionamiento, pero AppEngine cuenta con 9 horas gratis en esta instancia. Por lo que para mantener el sistema diariamente (24 horas), el precio ascendería a lo equivalente a las 15 horas por el precio comentado para cada día de funcionamiento. Por lo tanto, el coste de mantenimiento mensual con la utilización de AppEngine sería el siguiente:

Standard Environment

Donde, “Standard Environment” representa la instancia “B”, y “Standard Environment 2” representa la instancia “F”. Toda esta información ha sido encontrado en la página Precios | App Engine | Google Cloud usando como sede física de las instancias Frankfurt (europe-west3).

3.1.2 Vercel

Ofrece un nivel gratuito, mientras no se supere los siguientes límites:

Vercel

Toda esta información ha sido encontrada en la página Limits de Vercel. Mientras estos límites no sean superados el despliegue en la plataforma de Vercel es gratuito, y en caso de que se excedan estos límites conlleva una espera de 30 días hasta poder retomar el uso de la aplicación o el aumento del nivel de pago a Pro, donde se tendría que llevar a cabo un pago de 20 dólares al mes.

3.1.3 Base de datos

Existen dos sistemas de BBDD para escoger, relacionales y no relacionales teniendo características muy diferentes. Para nuestra aplicación hemos elegido usar bases de datos no relacionales para el correcto funcionamiento e integración del sistema. Hemos encontrado dos opciones factibles, que son PlanetScale y Mongo Atlas.

• PlanetScale: Para una base de datos con menos de 5 GB de almacenamiento, esta solución en el servicio de PlanetScale es la más recomendable teniendo un nivel gratuito muy extenso, con la capacidad de dar servicio a las aplicaciones que lo usen.

PlanetScale

• Mongo Atlas: Para una base de datos no relacional, el servicio de Mongo Atlas es el más recomendable, con la capacidad de dar servicio a las aplicaciones que lo usen. Cuenta con 3 tipos de planes y cada uno de ellos con distintas instancias.

MongoAtlas

3.1.4 Amazon AWS

Otra opción para el despliegue del backend es la de utilizar Amazon AWS, que además cuenta con planes de precio bajo demanda. Estas son algunas de las instancias disponibles:

Planes de AWS

Planes de AWS

En nuestro caso, la instancia más adecuada sería la m7gd.2xlarge, la cual nos aseguraría un gran rendimiento a un muy buen precio. Suponemos un uso de 4 horas diarias, por lo tanto serían 120 mensuales. Esto nos daría un coste de 120 x 0,4763 = 57,156USD mensuales, equivalente a 52,74€ mensuales.

3.1.5 Conclusión

Teniendo en cuenta lo expuesto anteriormente, hemos visto viables 4 opciones para el despliegue de la infraestructura de la aplicación teniendo en cuenta la calidad del sistema:

La primera opción considerada es la de App Engine. En esta, se utilizará una instancia “F” para el frontend (NextJs) y una instancia tipo “B” para el backend (FastApi). El precio de la instancia “F” sería gratis gracias a las 28 horas que ofrece AppEngine de manera gratuita en su plataforma, mientras que la de la instancia “B” sería un total de 65.60€ mensualmente. Respecto a la base de datos, utilizando el servicio más barato que ofrece donde tenemos un almacenamiento de 50GB, una RAM de 3.75GB y tipo SSD el coste total es de 17.28€ mensuales.

Por lo tanto, el precio mensual total para el despliegue del sistema ascendería a 65.60€ + 0€ + 17.28€ = 82.88€.

Otra opción, que es la segunda, es para el despliegue de la infraestructura necesaria para la aplicación, consistiendo esta en una aplicación para el frontend realizada en NextJs, otra para el backend con la tecnología FastAPI y su base de datos correspondiente. Podría ser una combinación de diferentes hosting diferentes, para aprovechar sus límites del nivel gratuito definidos anteriormente (podría ser utilizados debido al poco tráfico y carga de nuestra aplicación). En este caso se utilizarían los servicios de App Engine para el backend de la aplicación, Vercel para el despliegue del frontend y por último el servicio de PlanetScale para la base de datos relacional.

El coste mensual de esta opción de infraestructura sería el costo mensual del backend en App Engine, ya que con el nivel gratuito de Vercel y PlanetScale sería suficiente. Este coste serían de 65.60€ + 0€ + 0€ = 65.60€ mensuales.

Esta opción de despliegue se basa en una estimación de la carga y tráfico de las organizaciones, Tertulia Cofrade Cirio y Costal y Asociación Ciudadana de Ayuda al Toxicómano, donde su requerimientos no superan los límites gratuitos de Vercel y PlanetScale. Pues los usuarios que van a utilizar el sistema son solo sus administradores.

La tercera opción que barajamos es buena en cuanto a rendimiento y funcionamiento, pero también la de mayor precio. En esta opción se utilizaría el servicio de Google Cloud para el despliegue de la aplicación, con el servicio de App Engine para el backend, Vercel para el frontend y Mongo Atlas dedicated para la base de datos. Este coste serían 65,60€ + 0€ + 57,00€ = 122,60€ mensuales.

La cuarta opción que barajamos, que es la mejor en cuanto a rendimiento debido a las instancias elegidas, es la de utilizar Amazon AWS para el despliegue del backend, Vercel para el despliegue del frontend y Mongo Atlas dedicated para la base de datos. Este coste serían 52,74€ + 0€ + 57,00€ = 109,74€ mensuales.

En el siguiente gráfico, la “Opción1” representa la opción de un hosting completo en AppEngine explicada previamente, y la “Opción2” representa un hosting en Vercel, App Engine y PlanetScale también detallada previamente. La "Opción 3" se basa en AppEngine para el backend, Vercel para el frontend y Mongo Atlas para la base de datos. La "Opción 4" se basa en Amazon AWS para el backend, Vercel para el frontend y Mongo Atlas para la base de datos. En el eje y se representa los subsistemas de los que está formado el sistema, y en el eje x el precio mensual de cada uno de ellos.

Comparativa de precios

Finalmente, como buscamos el mejor rendimiento del sistema, creemos que la mejor opción es la cuarta. Es decir que nos decantamos por el servicio de Amazon AWS para el backend, Vercel para el frontend y Mongo Atlas dedicated para la base de datos.

3.2 Costes de APIs de verificación de email

Para la verificación de los correos electrónicos de los usuarios, se ha decidido utilizar una API de verificación de email. En este caso, se ha elegido la API de SendGrid, que ofrece distintos planes y es una de las más populares en el mercado. Los planes que se ofrecen son los siguientes:

Comparativa de precios

En nuestro caso, como se comentó previamente, con la poca carga de usuarios que va a recibir la aplicación, el uso del plan gratuito será suficiente para la verificación de los correos electrónicos de los usuarios. En este caso, el plan gratuito ofrece 100 correos electrónicos al día, lo cual es suficiente para el uso que se le va a dar a la aplicación. Por lo tanto, el coste mensual de la API de verificación de email es de 0€.

En caso de que cambiasen las políticas de uso de la API de SendGrid o se superasen estos límites y se tuviese que cambiar, optaríamos por el plan Essential que ofrece hasta 50.000 correos mensuales por 19.95€ al mes.

3.3 Costes de SLA

En nuestro caso, establecemos un SLA (Service Level Agreement) para el soporte al cliente que comprende la resolución de incidencias, solicitudes de usuarios y RFC (Request for Change) con los siguientes tiempos de respuesta (TTR):

• Resolución de Incidencias: 30 minutos
• Solicitudes de Usuarios*: 60 minutos
• RFC: 4 horas

Además, se tiene en cuenta que la cantidad media de estos son:

• Resolución de Incidencias: 50 peticiones/mes
• Solicitudes de Usuarios: 20 peticiones/mes
• RFC:2 petición/mes

Para calcular los costes mensuales del SLA, primero calculamos el número total de horas dedicadas a cada tipo de servicio al mes:

• Resolución de Incidencias: 25 horas/mes
• Solicitudes de Usuarios: 20 horas/mes
• RFC: 8 horas/mes

Para el soporte al cliente se contratará a un técnico con un sueldo de 20€/hora, que se encargue de gestionarlo y dar solución a los problemas que puedan surgir. A continuación, calculamos los costes asociados a cada tipo de servicio:

• Resolución de Incidencias: 25 x 20 = 500€
• Solicitudes de Usuarios: 20 x 20 = 400€
• RFC: 8 x 20 = 160€

Por lo tanto, el coste total mensual del SLA sería:

• Coste total mensual del SLA: 500€ + 400€ + 160€ = 1060€

Este sería el costo mensual total de cumplir con el SLA para nuestro proyecto de software.

3.4 Costes de personal

En nuestro caso, dado que tenemos una carga de usuarios mínima, ya que solo los administradores de las ONG utilizan el sistema, consideramos adecuado contratar a 2 desarrolladores para asegurar el funcionamiento continuo del sistema una vez esté completamente operativo.

Como mencionamos anteriormente, suponemos un salario para los desarrolladores de 11.25 €/h. También estimamos que cada desarrollador dedicará 5 horas semanales a mantener el sistema. Por lo tanto, el costo mensual de asegurar el funcionamiento del sistema es de: 11.25 x 5 x 2 x 4 = 450.00€. El costo total del personal para asegurar el funcionamiento del sistema durante 20 meses es de 450.00€ x 20 = 9000.00€.

También, consideramos adecuado contratar a un GDPR Officer para asegurar el cumplimiento de las normativas de protección de datos una vez finalizado el proyecto. Para ello, estimamos un sueldo medio de 22.50€ por hora, y una dedicación semanal de 2 horas. Por lo tanto, el coste de GDPR para 20 meses es de 22.50 x 2 x 4 x 20 = 3600.00€.

Por último, consideramos adecuado contratar a un CM una vez finalizado el proyecto. Para ello, estimamos un sueldo medio de 13.50€ por hora, y una dedicación semanal de 1 hora. Por lo tanto, el coste de marketing para 20 meses es de 13.50 x 1 x 4 x 20 = 1080.00€.

Coste total de personal = 9000.00€ + 3600.00€ + 1080.00€ = 13680.00€

4. Costes de contingencia

Hay que tener en cuenta que a la hora de analizar y prever los riesgos, también es necesario desarrollar un plan de contingencia para cada uno de ellos. Esto conlleva a que se tengan que dedicar una serie de costes para estos planes. Para este sistema, suponemos un 15% de los costes totales a dedicar a los planes de contingencia, ya que se suele recomendar una cifra entre un 10% y un 20% de manera general.

Teniendo en cuenta todos los costes, se obtiene un coste de contingencia de 9566.75€.

5. Coste total de la propiedad

Teniendo en cuenta la estimación de costes de desarrollo del proyecto, y la estimación respectiva a la operación del sistema, a los costes de GDPR y a los costes de contingencia, nos queda el siguiente Coste Total de la Propiedad (TCO) para 2 años, diferenciando entre los 4 meses de desarrollo y el resto de los 20 meses para completar los 2 años:

El coste total de la propiedad para 24 meses es de 97,6K.

6. Estado actual del TCO

Para el estado actuaal del TCO se tiene en cuenta lo siguiente:

• En el eje X se representa las 15 semanas que dura el proyecto
• En el eje Y se representa el Capex dedicado a cada una de las semanas, donde el coste ideal es el Capex total entre las 15 semanas, por eso es un valor constante. Para esto, se tienen en cuenta el coste del personal de desarrollo y el coste del material amortizado
• El coste real de cada semana tiene en cuenta las horas dedicadas por cada miembro teniendo en cuenta el rol y responsabilidad, y los costes de material amortizado